Render strips serially on the audio thread instead of using rayon - #1006

Systems and components

• observed — crates (service) was modified; 1 changed file maps to changed impact.

Before / after behavior

• observed — Modified behavior in crates/mix/src/lib.rs: run_strips no longer dispatches work to Rayon when called on the audio thread; that call now falls through to the serial path. Calls from other threads still use Rayon when there are at least four strips.
• observed — Modified behavior in crates/mix/src/lib.rs: The existing test assertions still check audio-thread marking for strip jobs. A new test asserts that an audio-thread call with eight jobs runs none of them on Rayon workers.

Explanation

The title states the main change: strips are rendered serially on the audio thread rather than through rayon. The raw summary confirms that run_strips skips rayon for four or more strips on the audio thread, and the objectives describe the same change, so the title matches the changeset.

Explanation

Issue #886 requires that the audio callback not block on rayon's shared global pool when it renders at least four strips. The whole-PR diff from the merge base to head changes run_strips in crates/mix/src/threads.rs. The new condition is work.len() >= 4 && !on_audio_thread(). The audio thread therefore renders its strips serially on its own thread. This is the first fix option named in #886. Pool workers run as_audio_thread(false, ...), so they are never marked as the audio thread. The wasm run_strips is unchanged. Offline rendering still uses the global pool, as the PR description states. The #886 line references (crates/mix/src/lib.rs:1283-1295) are stale. The current code is in threads.rs. The regression test audio_thread_tests::the_audio_thread_never_hands_strips_to_the_rayon_pool marks a spawned thread as the audio thread, runs run_strips on 8 strips, and asserts that no strip sees rayon::current_thread_index() as Some. Without the fix, the parallel path sends these strips to pool workers, so the test fails. With the fix, the count is 0. I did not run the test or cargo xtask ci. This verdict relies on the diff and test code.

Explanation

The whole-PR diff for crates/mix/src/threads.rs contains the #886 fix, the regression test, and test support changes. The added and removed line counts (+26/-10) match the AI summary for that file. The run_strips change implements #886 directly. The new regression test verifies it. The #[cfg(test)] to #[cfg(all(test, not(target_arch = "wasm32")))] change is needed because the module uses rayon and the native run_strips. The helper seen_by_strips now returns Result so that a missing strip or a panicked render thread is reported. The existing strips_rendered_for_the_audio_thread_count_as_the_audio_thread_and_only_then assertions now compare against the expected vectors. These edits support the audio-thread tests and do not change behavior outside them. No wasm run_strips, H.264 decoder pool, or public declaration changes appear in the diff. The AI summary lists threads.rs as the only changed file. I did not independently confirm the absence of changes in other files, so this verdict relies on the diff of threads.rs and that summary.

Explanation

Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 2 functions across 1 files.

• Create a new PR